\documentclass[12 pt]{article}

\usepackage{graphicx}
\usepackage{amsfonts}
\usepackage{amsmath, amsthm}
	

\pdfpagewidth 8.5in
\pdfpageheight 11in

\setlength\topmargin{0in}
\setlength\headheight{0in}
\setlength\headsep{0in}
\setlength\textheight{8.75in}
\setlength\textwidth{6.5in}
\setlength\oddsidemargin{0in}
\setlength\evensidemargin{0in}
\setlength\parindent{0.25in}
\setlength\parskip{0.25in}


\begin{document}

\title{Group Wireless Location Tracking With An Android Sink}
\author{Ronny L. Bull, Alexander B. Stuart, and Edward Spetka\\State University of New York Institute of Technology\\\{bullr,stuarta,spetkae\}@cs.sunyit.edu}
\date{Professor Geethapriya Thamilarasu\\April 25, 2012}

\maketitle
\clearpage
\onecolumn
\tableofcontents
\clearpage
\listoffigures
\listoftables
\twocolumn

\begin{abstract}
This paper will propose a location tracking solution that utilizes Micaz sensor motes running TinyOS equipped with a GPS sensor in order to send an individual mote's location to an Android device such as a tablet or smart phone. A custom application was developed for Android that plots the location of the mote on a map in order to provide a user friendly mobile interface for viewing the location of all deployed motes.
\end{abstract}


\section{Introduction}

In both emergency and non emergency situations, the need may arise to quickly locate all members of a party. An applicable example is an emergency rescue party searching for a lost hiker in the forest or locating emergency personal. The proposed solution consists of a mobile sink device, such as an smart phone or tablet, that collects data from the networked source nodes carried by the individual party members. The transmitted GPS data from the wireless sensor nodes can be used to dynamically map the geographical location data of all party members.


\section{Background}

This paper presents the results from testing a localization method using Micaz sensor nodes and an Android smart phone. In the past, wireless sensor network (WSN) technology has been used in similar applications. Other\\ projects have implemented localization algorithms using GPS technologies to gather data for the tracking algorithm that processes the sensor data at a base station. None of these studies have integrated the sink with modern smart phone technology. By using a smart phone as a sink instead of a desktop computer, additional flexibility and mobility are achieved. There are very few user friendly, portable, and inexpensive wireless GPS technologies available to the public. By using Micaz sensors and an Android smart phone, it demonstrates that this type of cost effective and accurate localization method is both possible and available.

The localization algorithm that is used in this study is similar to the one used by Stoleru, He, and Stankovic's work\cite{stole}. The idea of localization is addressed in a similar manner to what is proposed in this paper. Their work uses GPS and a similar Mica2 mote to transmit a GPS signal every few minutes to accurately track the path of an object as done in this paper. They focused their study on different measurements to calculate accuracy of the GPS and conduct performance evaluations of the GPS system. The work done in this paper by contrast will focus on the base station. It will integrate smart phone technology with the WSN to gather, process and display data. The authors of the related work utilized a laptop as their base station in order to collect their data. The laptop lacks the mobility and battery longevity of a smart phone.

This paper will show that by using TinyOS, Micaz sensor boards and the MTS420 sensor boards with an Android smart phone, one can drive a WSN application that uses the Android device as the sink node. One of the goals accomplished in this project is to create a GPS implementation that takes into account the necessity for user friendliness. It is expected that this system  will be used to locate someone in a search and rescue situation or in other situations of elevated danger where time and efficiency are of the essence. This device must be user-friendly, convenient and mobile.

This project demonstrates the potential for a convenient, low cost GPS based system for a broad range of location scenarios. The application is stored as an application on the Android device, and is compatible with a wide array of devices running the Android operating system such as smart phones and tablets.



\section{Related Work}

For the purposes of this experiment, assumptions are made that energy efficiency would not be a primary consideration. The focus of this application is gathering GPS data rather than energy efficient data collection. It is assumed that environmental factors encountered during the tracking of a wireless sensor through a given environment would not hinder the ability to effectively track the sensor mote.
The sensors used in this paper's research had limited battery power, storage, and computational power. Therefore it would be necessary to be mindful of the energy consumed by the motes during the tracking process. One of the available options is to consider the use of an energy efficient tracking protocol to track a single mobile agent through the network while maintaining its positions and minimizing energy consumption of the nearby motes. This was done by the location tracking protocol proposed by Tseng, Liu, and Feng only allowing motes closest to the moving target to broadcast\cite{tseng2}. The reason for not using this protocol is it still has not been perfected. Although it has been proven to reduce energy costs, the sacrifice of accuracy is not acceptable in this project.

When tracking the location of an object, there are various methods of obtaining its geolocation. The most popular is to disperse sensor motes across a field and allow them to collect and pass location information back to a sink node\cite{stole}. This method can be used to track an object that is not carrying any type of sensor. This approach was not used in this experiment. The location tracking method employed in this experiment was that of an empty environment where the object is deployed carrying a sensor with a GPS board attached transmitting a signal. The advantage of this method is the ability to track an object through empty field where no other sensor nodes must be deployed in order to acquire the location data. 

This paper's work specifically deals with the tracking of sensor nodes in differing environments. One of the main concerns during the tracking process is maintaining the precision and accuracy of the location data. The GPS device used in the tracking experiment is similar to the token object being tracked by Manley, Nahas, and Deogun's analysis\cite{man}. The method used in their research ensured accuracy by gathering external environmental data such as landmarks that might be useful in more precisely identifying the target object's specific location. They also utilized a technique known as dead reckoning. This technique calculates the distance traveled by the object and uses displacement to verify calculations to maintain accuracy in their movement measurements. Another\\ method that has been proposed to maintain accuracy utilizes the signal strength and a complex algorithms to achieve finer and more precise location estimates\cite{cen}. This would be done using the Received Signal Strength Indicator (RSSI) to retrieve and calculate distance values. Using such methods would have increased GPS accuracy. Due to the configuration of the experiment, mainly the network setup, it was not possible to take advantage of such techniques. In contrast, the method used in this paper's implementation did not allow for the use of these mechanisms, only the basic packet send and receive. 

The approach of Tseng, Kou, Lee, and Huang is similar to the approach used in this experiment. In their approach for tracking they used the implementation of virtual signal sources, which could be used if only one position could be located\cite{tseng}. In this approach, two virtual signal sources are incorporated into the square method for location estimation and tracking. This simulation locats the position of a mote using a minimal network. As pointed out by Tseng, Kou, Lee, and Huang, the more densely populated the network is, the easier triangulation, trilateration and multilateration of a coordinate becomes\cite{tseng}. The authors describe the methodology behind the triangulation of a moving sensor node in the field using this technique. Assuming sensors have been distributed in the field, then a monitoring agent could be deployed. In this protocol, the agent would migrate to the node nearest to the object and continuously broadcasting its location on each stop. Using this method would increased accuracy in this project. However the ultimate goal was transmitting in a minimal network where only one node transmits GPS data. The reasoning behind the decision is not to use these experimental node estimation and tracking techniques was simply that an array of nodes was not utilized. The experiment is to attempt to locate nodes using GPS signals without the need to do expensive processing tasks such as triangulation, trilateration or multilatration. Therefore, these methods were taken into consideration but not incorporated in the project design. 

In contrast the approach of Stoleru, He, and Stankovic suggests having a moving object carry a GPS board and the object broadcast a GPS signal from its current location periodically\cite{stole}. Stoleru, He, and Stankovic's experiments used Mica2 sensors and GPS boards to prove that localization is possible with an error range within 1-2 meters. The wireless output was sent to laptop for processing.

In this experiment, an approach similar to Stoleru, He, Stankovic was taken but in addition mobile phone integration provides us with a better graphical display of the data, similar to the work of Keally et. al\cite{keally}. We use mobile phones as a window to view the network. Smart phones offer practical solutions for integration between the WSN and the end user. We are able to utilize the mobile phone hardware and software for accurate and efficient data aggregation. This provides a more powerful interface for users to perform interpretation and analysis. This project's interface extends the work of Stoleru, He, and Stankovic by incorporating a powerful Google maps integration. 



\section{Prerequisite Knowledge}

\subsection{NMEA GPS Packets}

The MTS420 GPS sensor used in this paper receives NMEA (National Marine Electronics Association) packets which contain the information needed to plot points on the Google Maps API. The NMEA packet is divided into three primary sections: MIP packet header, command/reply fields, and the checksum. Figure \ref{fig:nmeapacket} gives an overview of the packet. 

\begin{figure}[ht!]
	\centering
	\includegraphics[totalheight=.11\textheight]{nmea}
	\caption[NMEA Packet Layout]%
	{The NMEA Packet Layout\cite{nmea2}}
	\label{fig:nmeapacket}
\end{figure}

Within the MIP packet header, there are four fields which are used for administrating the packet such as synchronization and packet size fields. The command/reply fields are the body of the packet where information needed for plotting is held. The field data is the most important element which will be discussed further later. The checksum portion of the packet contains fields vital to verifying the contents of the packet against corruption or tampering.


\subsubsection{NMEA Sentences}

The field data contains a list of fifteen comma delimited elements known as sentences which provide detailed positioning information. An example is shown in table \ref{fig:nmearaw}.

\begin{table}
	\begin{center}
		\$GPGGA,123519,4807.038,N,01131.000,E,
		1,08,0.9,545.4,M,46.9,M,,*47
		\caption[Sample NMEA Packet Sentences]%
		{Sample NMEA packet internals consisting of sentences.}
		\label{fig:nmearaw}
	\end{center}
\end{table}

The first sentence, \$GPGGA in the example, is the sentence which informs the receiver what type of NMEA packet it is. It always starts with \$GP and is then followed by three characters which represent the device. In table \ref{fig:nmearaw}, \$GPGGA represents fix information. Other possible sentences are \$GPMSS which contains beacon receiver information and \$GPVBW which contains dual ground and speed information. Other sentences are possible but only certain sentences work with select devices. For example, the \$GPGGA sentence that works on the Micaz motes also works on Garmin and Magellan devices.

The next sentences in the field data are the position sentences\cite{nmea}. The first position sentence is a time stamp. In table \ref{fig:nmearaw}, 123519 is the time stamp which represents that the fix was taken at 12:35:19 UTC. The next two position sentences are the latitude and direction which in table \ref{fig:nmearaw} is 4807.038,N and corresponds to 48$^\circ$ 07.038' north. The following two position sentences are the longitude. In table \ref{fig:nmearaw}, 01131.000,E corresponds to 11$^\circ$ 31.000' east. The seventh sentence is the fix quality which is represented by an integer value zero through eight. Typically, as in table \ref{fig:nmearaw}, the value should be 1 which means there is a good GPS fix. The eighth field is an integer that represents the number of satellites being tracked. In table \ref{fig:nmearaw}, this is 8. The ninth field is the horizontal dilution which is 0.9 in table \ref{fig:nmearaw}. The next two sentences are the altitude in meters. In table \ref{fig:nmearaw}, this is 545.4,M. The next two sentences refer to the height of geoid (mean sea level) above the WGS84 ellipsoid in meters. Please note that the WGS84 ellipsoid is now out date, but would still be used by the Micaz sensors used in this paper since they were made before 2010\cite{geoid}. In table \ref{fig:nmearaw}, this is represented as 46.9,M. The next two sentences are optional and contain the time in seconds since the last DGPS update and DGPS station ID number respectively. The final field is the checksum which always begins with an asterisk. In table \ref{fig:nmearaw} it is *79.


\section{Application}

Since wireless sensor networks were first developed for military applications, various uses for GPS location tracking using the proposed system in military scenarios will be considered. Sensors can be used to track soldiers, vehicles, helicopters, and airplanes on the battle front functioning as a collective. Using GPS to track the locations of all these entities gives the military leaders a better understanding of exact positioning and formations of the troops in relation to each other. The data could indicate how the war is progressing and if progress is being made or lost. From the GPS group data collected, assumptions could be made leading to specific adjustments of troops and other entities on the field of battle. The GPS group data could allow for these adjustments to be as specific as where exactly to move (coordinates) and when. The application could allow for data to be stored later used for statistical analysis. With careful analysis, observations in data trends can be seen better decisions can be made. 

Police, fire, and emergency medical-service units could use the proposed GPS location tracking system to track their colleagues during active duty. For example while in the line of duty a police task force might investigate a large urban area. During this time if a team member was to be separated or taken hostage the team could know his or her exact location in order to conduct a rescue operation. Firefighters face many dangers entering forest fires or dangerous buildings. During active duty, a team could enter an area and get separated or trapped. By using the GPS location tracking, the group could pinpoint their team member's exact location allowing for a fast rescue. Emergency medical services (EMS) could benefit from a GPS application such as the one presented as well. In the case of a large scale accident for example, the EMS teams arriving on the scene could broadcast their GPS coordinates to other EMS teams that show up to help. As a consequence, the newly arrived EMS teams would be aware of where they are needed and where there is already enough help. This would allow the EMS teams to aid victims more efficiently and effectively. 

In these high risk situations the most important consideration is safety. The main purpose for the GPS location tracking in these scenarios is to allow the sharing of location information so these agencies could provide easier, safer, and more effective relief during the emergency situation.

The GPS location tracking platform has many other day to day applications as well. The GPS location tracking platform could be used in the farming industry for instance. GPS location tracking is very useful to farmers who which to conduct field mapping, soil sampling, tractor guidance, and other related tasks. Using the proposed GPS location tracking platform could allow farmers to work during low field visibility conditions such as rain, dust, fog, or even at night. Farmers can use the location information collected by GPS transmission to map field boundaries very accurately. They can calculate their precise acreage allowing them to purchase the right amount of chemicals and fertilizers they need. As for sampling soil, the GPS location tracking platform allows farmers to accurately navigate to a specific location in the field and to collect soil samples. In this manner, the sample has been collected in the same location producing more accurate data.


\section{Implementation}

A user friendly smart phone interface was developed under the Android environment utilizing the Google Maps and Google Location APIs. The smart phone interface consists of a map overlay that accepts GPS location information sent to it from a base station. When the application is started, the map loads a default starting point and waits for a GPS location transmission from the base station as shown in figure \ref{fig:a1}. When the application receives a mote's GPS coordinates from the base station, it marks the mote's location on the map and waits for a new set of coordinates to arrive as in figure \ref{fig:a2}. Each time a new set of GPS coordinates are received by the Android device from the base station, the corresponding mote's location is updated on the map and it's previous location is denoted by the green Android robot icon as illustrated in figure \ref{fig:a3}.

\begin{figure}[ht!]
	\centering
	\includegraphics[totalheight=.3\textheight]{appstart}
	\caption[Android Application Startup Screen]%
	{Android application screenshot of the startup screen.}
	\label{fig:a1}
\end{figure}

\begin{figure}[ht!]
	\centering
	\includegraphics[totalheight=.3\textheight]{applocation1}
	\caption[Android Application Initial GPS Location]%
	{Android application screenshot of the mote's initial GPS location.}
	\label{fig:a2}
\end{figure}

\begin{figure}[ht!]
	\centering
	\includegraphics[totalheight=.3\textheight]{applocation2}
	\caption[Android Application Updated GPS Location]%
	{Android application screenshot of mote's updated GPS location.}
	\label{fig:a3}
\end{figure}

During prototyping, access to two Micaz motes, a programming board, and two MTS420/400CC sensor boards was available. The initial goal was to have the motes communicate wirelessly to the Android device over the IEEE 802.11 protocol, however this proved to be impractical and instead it was decided to setup a base station to receive the GPS information from the field mote and relay it to the Android device for processing. Visually this is shown in figure \ref{fig:imp} where the base station is C, the field mote is B, and the GPS equipped mote is A. The base station consists of a minimal Ubuntu 10.04 LTS server installation setup with TinyOS 2.1.x as well as all of the required NMEA drivers, header files and libraries. The Micaz mote is configured running the standard BaseStation application from the\\ TinyOS repository, and connected to the Ubuntu server machine via the programming board and a USB cable. A simple Java application listens on the serial port that the mote is connected to device /dev/ttyUSB1. When the base station mote receives packets over the radio from a field mote it forwards them over the serial connection to the computer. Scripts are implemented on the computer that parse the GPS location information from the packet data, and forward only the relevant location information either over the Internet or via WiFi to the Android device, shown as D in figure \ref{fig:imp}, which in turn marks the mote's location on the map. Notice in figure \ref{fig:imp} that data flows from A to D and does not travel from D to A.

\begin{figure}[ht!]
	\centering
	\includegraphics[totalheight=.3\textheight]{implementation}
	\caption[Implementation Overview]%
	{High level implementation overview.}
	\label{fig:imp}
\end{figure}


\begin{figure}[ht!]
	\centering
	\includegraphics[totalheight=.27\textheight]{base_mote}
	\caption[Picture of Micaz Mote Running the BaseStation Application]%
	{Picture of the Micaz mote running the basestation application and interfacing via USB to the desktop}
	\label{fig:base}
\end{figure}


\begin{figure}[ht!]
	\centering
	\includegraphics[totalheight=.3\textheight]{gps_mote}
	\caption[Picture of Micaz Mote Utilizing the GPS Sensor]%
	{Picture of the Micaz mote utilizing the GPS sensor}
	\label{fig:gps}
\end{figure}

\section{Conclusion}


\subsection{Parsing GPS Data}

One challenge of this project was to translate the GPS data into a format expected by the Google Maps API and to parse only the information needed. It was assumed that the GPS sensor mote would collect of the information contained in a standard NMEA packet. However, the public code for working with NMEA packets only included the basic sentences. After collecting a NMEA packet, the GPS would send the packet to the base station mote who forwarded the packet serially to a desktop computer. No parsing of data occurred until the desktop computer. This was a design consideration since a standard desktop is not power limited and has a large computational power. The Perl script does not do any type of error checking or error correction. The data is blindly parsed and passed to the Google Maps API.

Once the packet arrived at the desktop, it was parsed by the Perl script. When the packet arrived, it was interpreted by the provided Java listener script which pulls down the TinyOS packet in its entirety. The packet consists of 21 single byte fields. For readable, these byte fields are displayed in hexadecimal by the listener script. Since the Google Maps API expects the only the longitude followed by the latitude in decimal, only those field are parsed and converted. The other sentences in the NMEA packet were ignored. If in the future the Google Maps API included new functionally, such as support for altitude, it would be simple to include the altitude sentence. 

\section{Critique}

During the prototyping, unforeseen issues were experienced getting the MTS420/400CC sensor board's GPS sensor to function correctly. After many failed attempts at code manipulation and sensor placement, it was discovered that the there were no working TinyOS drivers for the MTS420/400CC GPS sensor. The specific issue was that the board never received any NMEA GPS packets. This was confirmed by another reference that successfully implemented the GPS sensors on revision MTS420/400CA and MTS420/400CB sensor boards\cite{stole}. However, the revision CC boards featured a different GPS chipset then the other version.Drivers that supported the GPS sensor on the revision CA and CB boards do not support the newer GPS sensor on the revision CC sensor board. In order to progress with development, incoming GPS packets were simulated directly in the sensor mote's code.  

\section{Future Work}

Future work on this topic is very plausible. Instead of using Micaz hardware that was unsupported by the TinyOS software, a different version such as CA or CB could be used to fully implement the proposed platform in this paper. Another issue that could be addressed is removing the desktop computer from the platform and instead use the Android device as the base station and conduct the NMEA packet parsing on it. Ideally, one could utilize the IEEE 802.11 wireless protocol which is currently difficult with the Micaz hardware and TinyOS software combination. Another option, if the Micaz hardware were to support it, is Bluetooth. Both the IEEE 802.11 and Bluetooth protocol are common on today's smart phones. Furthermore, one could program the TinyOS software with both the GPS and BaseStation applications to allow for a WSN to forward information to the Android base station as in figure \ref{fig:wsn}. In the figure, A$_{1-3}$ motes and the B mote are equipped with GPS. A$_{1-3}$ is able to forward NMEA packets to B who in turn is able to forward to the Android base station. Notice that C, which was present in \ref{fig:imp} has been removed and therefore improving the network. Fault tolerance is increased, complexity is reduced, and hardware requirements are reduced. One last area that could be improved is the parsing script. The Perl parsing script and the Java listener script could be merged together into a single language script for consistency.

\begin{figure}[ht!]
	\centering
	\includegraphics[totalheight=.3\textheight]{implementation-ideal}
	\caption[Ideal Wireless Sensor Network]%
	{An ideal wireless sensor network that connects all motes to the Android base station.}
	\label{fig:wsn}
\end{figure}

\section{Conclusion}

Situations arise in which is it critical to have ability to quickly and efficiently locate an object or a group of objects. This is true for military scenarios, emergency scenarios, and even leisure scenarios. In this scenario, it would be ideal to have a limited amount of common hardware that could assist in this task. This paper proposed a solution to such scenarios utilizing Micaz motes with a GPS attachment, a desktop computer base station, and a common Android device whether is be a smart phone or tablet. Unfortunately, the Micaz hardware is not fully supported by the TinyOS software which required simulation to implement. However, the ability to parse NMEA packets and display coordinates using the Google Maps API was successful when using the simulation GPS coordinates.

\clearpage

\begin{thebibliography}{12}

\bibitem{KO} A. Ko and Y. Lau. \emph{Robot Assisted Emergency Search and Rescue System With a Wireless Sensor Network}. International Journal of Advanced Science and Technology. Vol 3. February 2009.
\bibitem{Kusy} Kusy et al. \emph{Radio Interferometric Tracking of Mobile Wireless Nodes}. MobiSys '07.
\bibitem{geoid}\emph{National Geospatial-Intelligence Agency}. Accessed 4/16/12. https://www1.nga.mil/ProductsServices\\/GeodesyandGeophysics/WorldGeodetic\\System/Pages/default.aspx
\bibitem{nmea}\emph{NMEA Data}. Accessed 4/16/12. http://www.gpsinformation.org/dale/\\nmea.htm
\bibitem{nmea2}\emph{3DM-GX3-35® Data Communications Protocol}. Accessed 4/16/12. http://www.scribd.com/doc/65036346/\\82/Wrapped-Raw-NMEA-Packet-0x81-0x01
\bibitem{stole}R. Stoleru, T. He, A. Stankovic. \emph{Walking GPS: A Practical Solution for Localization in Manually Deployed Wireless Sensor Networks}. Proceedings of the 29th Annual IEEE International Conference on Local Computer Networks. 2004.
\bibitem{tseng}Y. Tseng, S. Kuo, H. Lee , and C. Huang. \emph{Location Tracking in a Wireless Sensor Network by Mobile Agents and Its Data Fusion Strategies}. The Computer Journal. Vol 47. No 4. 2003.
\bibitem{man}E. Manley, H. Nahas, and J. Deogun. \emph{Localization and Tracking in Sensor Systems}. Proceedings of the IEEE International Conference on Sensor Networks, Ubiquitous, and Trustworthy Computing. 2006.
\bibitem{cen} A. Cenedese, G. Ortolan, and M. Bertinato. \emph{Low-Density Wireless Sensor Networks for Localization and Tracking in Critical Environments}. IEEE Transcations on Vehicular Technology. Vol 59. No 6. 2010.
\bibitem{tseng2}Y. Tseng, W. Liu, and K. Feng. \emph{Mobile Location Tracking Scheme for Wireless Sensor Networks with Deficient Number of Sensor Nodes}. Emerging Communications for Wireless Sensor Networks.
\bibitem{keally} Keally et. al. \emph{PBN: Towards Practical Activity Recognition Using Smartphone-Based Body Sensor Networks}. SenSys’11. 2011.
\bibitem{pas} G. Paschos, E. Vagenas, S. Kotsopoulos. \emph{Real-time Localization for Wireless Sensor Networks with multiple beacon transmissions}.


\end{thebibliography}


\end{document}
